Method and system for providing access to web services

ABSTRACT

Software applications are provided access to web services, such as Parlay X web services, by providing a Parlay gateway permitting access to web services and including a Parlay framework. A set of modules having service interfaces for the software applications is provided, the modules in the set acting as proxies in order to perform requests for access to web services on the framework of the Parlay gateway on behalf of the software applications.

FIELD OF THE INVENTION

The present invention generally relates to techniques for providingaccess to web services.

The invention was developed by paying specific attention to the possibleuse in accessing telecommunication network capabilities and providingsoftware applications access to Parlay X web services.

Reference to these possible, specific applications is in no way to beconstrued as limiting the scope of the invention: in fact, the inventionis applicable in introducing a secure and controlled access to anygeneric web service.

DESCRIPTION OF THE RELATED ART

In recent times, a growing interest is being demonstrated for thoseservices that mix information technology applications (e.g. corporateinformation systems, internet/web applications) with the capabilitiesprovided by a telecommunication network, such as capabilities forsetting-up and controlling calls, getting the location of mobileequipment, sending and receiving SMSs or MMSs.

Such applications can be developed and deployed by actors different fromtraditional network operators, such as corporate entities or providersof services over the “big” Internet. Examples of such applications arenetwork call centers, fleet management applications or “click-to-dial”applications. In this case the network operator will need to provideaccess to its network capabilities for applications deployed in a domaindifferent from the domain of the network operator.

Parlay is a solution that allows software applications to accesscapabilities implemented in telecommunication networks, includingcontrol of phone calls, interaction with users through differentcarriers (e.g. voice, SMS, USSD), localization of terminals,status/presence information of end-users, control of data sessions,terminal capability access, and account management and content-basedcharging.

In the following, the present invention is referred in the descriptionand in the claims to Parlay standard as specified in ETSI and 3GPPdocuments. However it is clear, as an expert on the field canappreciate, that the present invention is applicable or directed eitherto any possible extension of the Parlay standard or to similar solutionsusing Parlay equivalent functions and interfaces.

General information on Parlay can be found in the following documents:

[Parlay] Open Service Access (OSA), ETSI ES 202 915-1 V1.1.1 (2003-01)

This is the latest Parlay specification (published by ETSI), whichdescribes the Parlay APIs for framework and service interfaces.

[ParlayXWP] Parlay X Working Group, White Paper, 16 Dec. 2002

This document describes the introduction of Parlay X web services andtheir possible relationship with a Parlay gateway.

[ParlayX] Parlay X Working Group, Parlay X Web Services Specificationv1.0, 9 May 2003

This is the latest specification of Parlay X web services.

[ParlayWSComparison] Parlay Web Services Working Group, Parlay WebServices Architecture Comparison, 31 Oct. 2002

This document compares the Parlay and web service architectural models,by pointing out the difference between the Parlay framework and therepository of web services implemented by as a UDDI server.

[ParlayWSDeployment] Parlay Web Services Working Group, Parlay WebServices Application Deployment Infrastructure, 31 Oct. 2002

This document presents some possible deployment scenarios of Parlay Xweb services, without however describing their realization in general,and the structure of the Parlay X web services in particular.

In Parlay (FIG. 1), interaction among software applications A1, A2, . .. , An and network capabilities NC is achieved through a set of serviceinterfaces, provided as application programming interfaces API by meansof a distributed processing mechanism DPM such as e.g. the Common ObjectRequest Broker Architecture (CORBA) overseen by the non-profitorganization named OMG (Object Management Group).

As the software applications can be deployed and operated in anadministrative domain different from the network operator domain, Parlayimplements some functions, named “framework” functions FI+FF that enablea secure and controlled access to the service interfaces SI.

The Parlay application programming interfaces API are implemented by aParlay gateway PG, which may comprise a distributed set of servers, eachof which implements the framework functions and/or the module toimplement the service interfaces SCS (named Service CapabilityServers—SCSs) by interacting with the network capabilities NC.

The Parlay gateway includes a framework module FI+FF, that performs thefollowing functions:

-   -   authentication of the applications;    -   authorization for the applications to access the network        capabilities;    -   registration of new service interfaces to be accessed through        the gateway;    -   management of the profiles containing the data characterizing        the subscription of an application to a Service Interface (e.g.        configuration data, limitations on the use, etc.);    -   binding of an application to a service interface (or, better the        module implementing the access to a service interface),        instantiated according to the corresponding subscription profile        data;    -   integrity management to verify the correct behavior of all the        components of the system (e.g. applications, modules        implementing the Service Interfaces).

The Parlay solution and APIs are published by ETSI, were adopted by the3GPP and form the so-called Open Service Access (OSA) standard.

As Parlay APIs are quite complex to use, several attempts to providesimplifications were proposed.

One of these is Parlay X. Essentially, Parlay X is a set of APIs (FIG.2, Parlay X Web Services), defined according to the web servicemechanism (i.e. they are defined by using the XML-based language WSDL,and are invoked with SOAP protocol (Simple Object Access Protocol) asdistributed processing protocol) that provide a greater level ofabstraction to network capability control and more oriented to webapplication developers. According to the Parlay X reference model,Parlay X web services could be implemented by Parlay X Servers PXS thatinteract with a Parlay gateway PG or with the network resources NE.

Specifically, in FIG. 1, A1, A2, . . . , An are applications that accessvia a distributed processing mechanism DPM (such as CORBA) a Parlay/OSAgateway PG. This includes service interfaces SI and respectiveassociated software modules SCS that implement the behavior of theParlay web services. The gateway PG also includes framework interfacesFI and framework functions FF. The network capabilities are generallydesignated NC.

In the Parlay X reference model of FIG. 2, the designation PA denotesParlay applications (in Java, C and so on), while the designation PXAdenotes Parlay X applications (in Java, C, XML Script and so on). TheParlay gateway, that interfaces with the applications PA via Parlay APIsis again designated PG. Access of the Parlay X applications PXA to thegateway PG and network elements NE is via Parlay X servers PXS.

A point still open in the Parlay X solution is how Parlay X web servicescan be accessed in a secure and controlled way by software applicationPXA deployed in third party administrative domains.

Certain possible solutions addressing this open point are described inthe document concerning ParlayWSDeployment cited in the foregoing. Thatdocument describes some possible deployment architectures for Parlay Xweb services (without however describing their realization), andspecifically proposes to interact with Parlay framework functions beforeaccessing of Parlay X web service. As a basic drawback, this arrangementrequires an explicit interaction of an application that wants to use theParlay X web services with the Parlay framework interfaces: such aninteraction is not appropriate for applications based on the web servicemodel.

In fact, the interfaces provided by the Parlay framework impose aninteraction model which is not aligned with the web service interactionmodel adopted for example by Parlay X web services: the Parlay frameworkinterface interactions are based on complex transactions of messageexchanges, which are quite different from the simple “request-response”interaction model of web services. Moreover, before obtaining access toa web service interface, applications based on web services do not haveto perform a set of authentication and authorization operations, such asthose required by the interaction of the Parlay framework.

A more detailed comparison among Parlay and the web service model isreported in the document ParlayWSComparison already mentioned in theforegoing.

Moreover, the document ParlayWSDeployment proposes to use protocolsconceived for “generic” web service secure invocations (e.g.WS-Security) in order to invoke Parlay X web services as well. Theseprotocols would be used to transport the information needed for theauthentication and authorization steps. Such a document suggests, inparticular, to add new servers, external to the Parlay architecture, toperform the authentication and the authorization steps of Parlay X Webservices.

The document referred to in the foregoing as [ParlayX] includes acaption to WO-A-02/11459.

In WO-A-02/11459 the problem is tackled of introducing a level ofabstraction on the application side (named PCP) in order to accessParlay gateway APIs. To that end, the applications are co-located in thesame system or, at least, in the same administrative domain with thesoftware modules that implement the abstraction layer. The arrangementof WO-A-02/11459 does not cover the issues related to the use of webservice technologies or, in particular, Parlay X Web Services.

OBJECT AND SUMMARY OF THE INVENTION

In view of the prior art considered in the foregoing, the need is feltfor arrangements adapted to implement a secure, controlled andconfigured access to web services such as Parlay X web services bysoftware applications deployed in third party domains.

More specifically, the need is felt for an arrangement that:

-   -   does not require additional servers external to the Parlay        architecture, thus making it possible to exploit the servers        already deployed in a Parlay solution, i.e. the Parlay framework        functions and the administrative systems used for configuring        the authentication, authorization and configuration data        associated to an application that wishes to use a web service        such as a Parlay X web service, and    -   is well integrated with the web service computational model: in        fact the Parlay X Applications, for example, are not required to        interact with additional servers in order to perform the        authentication and the authorization steps.

The object of the present invention is thus to provide an improvedarrangement fulfilling those needs.

According to the present invention, that object is achieved by means ofa method having the features set forth in the claims that follows. Theinvention also relates to a corresponding system, a relatedcommunication network as well as a related computer program productloadable in the memory of at least one computer and including softwarecode portions for performing the steps of the method of the inventionwhen the product is run on at least one computer. Reference to at leastone computer is evidently intended to take into account the fact thatthe invention is adapted to be implemented in a distributed processingarrangement.

A preferred embodiment of the arrangement described herein is a methodfor providing software applications access to web services, by:

-   -   providing a Parlay gateway (PG) permitting access to web        services, the Parlay gateway (PG) including a Parlay framework        (FW), and    -   providing a set of modules (PX WS) comprising service interfaces        for the software applications, the modules (PX WS) in question        acting as proxies in order to perform requests for access to web        services on the framework (FW) of the Parlay gateway on behalf        of the software applications.

In general, as known, a proxy function is a module or combination ofmodules which perform actions on behalf of a requester (i.e. thesoftware application) in order to grant the access to external services(i.e. web services); for example a proxy function can compriseauthentication, authorization, execution requests on the Parlay gatewayfunctions/modules on behalf of the Parlay X applications.

A preferred embodiment of the arrangement described herein offers thefollowing advantages:

-   -   a web service such as a Parlay X web service can perform the        authentication of software applications that wish to access it        by exploiting the authentication mechanism provided by the        framework functions in a Parlay gateway;    -   a web service such as a Parlay X web service can verify whether        a software application that wishes to access it is authorized or        not by exploiting the authorization mechanism provided by the        framework functions in a Parlay gateway;    -   the behavior of a web service such as a Parlay X web service can        be customized, by exploiting the service property mechanisms        provided by the framework functions in a Parlay gateway.

From the application viewpoint, the arrangement described hereinguarantees that applications can access Parlay X web services and anyother web services that adopt WS-Security invocation protocol (oralternative web service secure invocation protocols), without explicitinteraction with additional servers in order to perform theauthentication and the authorization steps.

It will be appreciated that the arrangement described herein is not perse related to how the web service methods can map on the Parlay serviceinterfaces in order to implement the control and monitoring of specificnetwork capabilities.

The proposed arrangement also solves the problem of introducing anabstraction layer in an administrative domain different from the domainwhere the applications are located, while also addressing applicationsdeveloped by means of web service based technologies, possibly deployedin an administrative domain different form the domain that implementsthe Parlay X web services.

Specifically, the presently preferred embodiment of the arrangementdescribed herein addresses the following requirements:

-   -   web services such as Parlay X web services are deployed in the        domain of the telecommunication operator and can be accessed by        applications deployed in third party administrative domains: the        interaction between the application and the web services is        performed through a WS-Security protocol;    -   the behaviour of the web services can be configured, application        by application, through subscription parameters: they can be        used for personalizing the behaviour, for defining conditions        for use and configuring data, e.g. those data concerning the        off-line provisioning of notification handling;    -   the implementation of web services is performed by exploiting        the components of a Parlay gateway already deployed in the        operator infrastructure, namely: authentication, authorization        and access control (e.g. use condition enforcement) is        implemented by interacting with the framework functions;        moreover, the configuration of the subscription parameters of an        application to a web service can be performed through the        administrative tools and interfaces of the Parlay framework;    -   the applications can access web services, in particular Parlay X        Web Services, as “normal” web services, without specific        operations related to the Parlay context.

BRIEF DESCRIPTION OF THE ANNEXED DRAWINGS

The invention will now be described, by way of example only, byreferring to the enclosed figures of drawing, wherein:

FIGS. 1 and 2, related to the prior art, were already described in theforegoing;

FIG. 3 is a functional block diagram showing the context of thearrangement described herein;

FIG. 4 is a functional block diagram showing the initialization phaseand method invocation within the arrangement described herein;

FIG. 5 is another functional block diagram showing the handling ofnotifications within the arrangement described herein;

FIG. 6 is still another functional block diagram showing theinteractions for session control within the arrangement describedherein; and

FIG. 7 is a flow chart illustrative of certain processes taking placewithin the framework of the arrangement described herein.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS OF THE INVENTION

By way of introduction, the basic components of the arrangementdescribed herein (FIGS. 3 and 4 to 6) will be presented by referring toa context including certain features/elements that were alreadydescribed in the foregoing.

Once again it will be appreciated that even though the rest of thedetailed description herein will be made by referring primarily toaccess to Parlay X web services, the arrangement described herein canalso be applied in providing secure and controlled access to—any—genericweb services, and not only to Parlay X web services.

Parlay X Applications (PXAs): these are software applications thatinteract with Parlay X web services in order to accomplish theirpurposes;

UDDI: this is a UDDI (Universal Description, Discovery andIntegration—or Interface) server that could be optionally used by ParlayX applications to retrieve the references to the Parlay X web services,according to the web service model;

Parlay X Server (PXS): it is a server (or multiple servers) that hostsand executes the implementations of PX WSs;

PX WSs: these are software modules that provide to the Parlay Xapplications PXAs Parlay X web services interfaces and behave as proxyin order to perform authentication, authorization, execution requests onthe Parlay gateway functions/modules on behalf of the Parlay Xapplications;

Parlay gateway (PG): it is a system, possibly distributed on multipleservers, that implements the functions to provide Parlay APIS; itconsists of:

-   -   a framework (FW), i.e. a module that implements the Parlay        framework functions and APIs, including authentication,        authorization, service discovery and selection, service        subscription profile management, service registration service        life-cycle;    -   SCS: these are modules that implement service interfaces, either        standardized by Parlay or proprietary; and    -   PX SCS: these are software modules that implement the behaviour        of the Parlay X web services, possibly allowing the        customization according to the data (i.e. service properties)        contained in the service subscription profiles handled by the        framework.

Administrative tools (AT): these are software applications for theconfiguration of the data related to the Parlay gateway (e.g. handlingof application subscription, configuration, etc.);

Network elements (NE): these are the network resources that implementthe network capabilities (e.g. location server, switches, SIP servers,SMS centers).

The typical interfaces/protocols used for the interactions meet thefollowing requirements:

-   -   the Parlay X applications (optionally) interact with the UDDI        server through UDDI protocol;    -   the Parlay X applications interact with the Web Services offered        by PX WSs by using WS-Security protocol (or alternative        protocols adapted to ensure secure access to web services);    -   PX WSs interact with the framework FW through the Parlay        framework APIs over a distributed processing mechanism, e.g.        CORBA;    -   PX WSs interact with PX SCSs through an API invoked over a        distributed processing mechanism, e.g. CORBA;    -   PX SCSs interact with the framework FW through the Parlay        Framework APIs over a distributed processing mechanism, e.g.        CORBA;    -   PX SCSs interact with the Parlay SCSs through the Parlay APIs        over a distributed processing mechanism, e.g. CORBA.

A preferred implementation of a Parlay X web service consists of twoparts, named respectively PX WS and PX SCS:

-   -   the PX WS part is a web service which implements the Parlay X        web service APIs, plus some generic methods for session        management; it behaves as a proxy on behalf of the application        in order to perform the operations of authentication, access        control on the framework and notification handling, as well as        method invocation on the corresponding PX SCS;    -   the PX SCS part implements the behaviour of the Parlay X web        service; it is an SCS for the Parlay framework and interacts        with it (the framework) through the standard Parlay APIs (e.g.        Service Registration and Service Life-Cycle); in particular, the        PX SCS part has to perform a registration phase to the framework        as any other SCSs; it could either use other SCSs in order to        access the resources or directly access them by using the        interfaces provided by the resources; its behaviour can be        configured according to the service properties subscribed by the        application, for personalization purposes or verifying        constraints/conditions (e.g. use conditions according to the        service level agreement or SLA) on the use of the Parlay X Web        Service.

The interface between the two parts is structured in the following way:

-   -   the interface offered by the PX SCS part to the PX WS part        consists of the same methods (transformed in IDL with additional        parameters to deal with the explicit transmission of security        data) provided by the Parlay X Web service to the application;    -   the interface offered by the PX WS part to the PX SCS part        consists of the methods to be invoked when the PX WS part has to        provide some notification (if the Parlay X web service is not        required to handle notification, this interface is not needed).

From the point of view of the development of a Parlay X Web Serviceimplementation, the Parlay X web service, including the control of usecondition are implemented in the PX SCS part; the PX WS part is, on theother hand, almost similar for all the Parlay X web services, and couldbe derived from a common software template.

A basic advantage of the arrangement described herein lies in theinterworking of the security mechanisms in the Parlay framework and inthe WS-Security protocol, which are based on “dual”/opposite principles,as better detailed in the following.

An application that has to use the Parlay X web service will subscribeit and provide the configuration data (e.g. for representingpersonalization requirements or the use conditions included in theservice level agreement, or SLA). It results in the subscription of thecorresponding PX SCS and in the configuration of its service properties:both operations are performed by using the interfaces/administrativetools provided by the framework FW. The service properties include acopy of the application password, which is the secret key shared betweenthe Parlay gateway and the application used to authenticate theapplication, and the off-line provisioned data concerning the handlingof notifications.

In addition to the methods included in the Parlay X web service, a PX WSprovides the following methods for session handling (the names providedherein have purely exemplary nature):

-   -   start-session (appl-id,call-backURL): this method is the first        method invoked by the application appl-id, in order to start to        use the Parlay X web service; call-backURL is the reference of        the web service provided by the application and invoked by the        Parlay web service in order to verify if the application is        still active;    -   close-session: this method should be invoked by an application        in order to terminate a session of use of the Parlay X web        service; an application, which terminates without invoking this        methods, is detected by the Parlay X web service as it has to        periodically invoke the call-back method still-alive (see below)        provided by the application;    -   challenging-PXWS (challenging-token)->hashed-token: this        (optional) method could be used by the application in order to        periodically check the identity and the active status of the        Parlay X web service. The identity of the Parlay X web service        is verified though a challenge mechanism: the Parlay X web        service has to return as a result the challenging-token hashed        with the application password (i.e. the shared secret key        between the application and the Parlay infrastructure).

Moreover, any application wishing to use a Parlay X web serviceimplements a web service with the following method:

still-alive (challenging-token)->hashed-token: this method is invoked bythe PX WS part of the Parlay X web service in order to check that theapplication is still active and to verify its identity, through achallenge mechanism; the application has to return as a result thechallenging-token hashed with the application password (i.e. a sharedsecret key between the application and the Parlay infrastructure).

A Parlay X application that is invoking a method of a Parlay X webservice includes authentication data in each of its invocations (e.g. byusing some WS-security mechanisms), including the applicationidentifier, the password in a digest format, and some additionalinformation (selected and/or generated by the application, e.g. atimestamp and a message identifier) used by the application to hash thepassword (e.g. the digest format of the password could be the result ofa hash algorithm that takes as a input the password, the additionalinformation). In order to verify the identity of the client application,the implementation of the Parlay X web service executes the same hashalgorithm, by using as input the stored password associated to theapplication identifier and the received additional information. Theauthentication succeeds if the result is equal to the received digestpassword. The same method and information are used by the Parlay X webservice implementations in order to provide the authentication data ininvocations performed to notify events to applications.

The interactions among the components are better described in FIGS. 4 to6 where the same references already described in connection with FIG. 3apply and the telecommunication operator domain (TOD) has beenspecifically highlighted: each interaction will be detailed in thefollowing subsections.

FIG. 4 shows the interactions for the start of a use session of a ParlayX web service and the invocation of its methods:

0—the application accesses the UDDI server in order to get the WSDLrelated to the needed Parlay X web service; the WSDL includes thebinding information on how to access the Parlay X web service providedby PX WS part of its implementation; this step could be optional in thecase the application had the possibility to receive the WSDL in analternative way (e.g. a direct communication);

1—the application requires to initialise a use session on the Parlay Xweb service, by invoking (by means of SOAP protocol) the start-sessionmethod; the PX WS part interacts with the Parlay framework (1′), byperforming the authentication phase on behalf of the application(details of the authentication procedure are provided below);

2—the PX WS performs on behalf of the application the selection of thePX SCS; the Parlay framework verifies whether the application isauthorized to use PX SCS: this check corresponds to verify is theapplication is authorised to use the Parlay X web service requested;

3—the PX WS performs on behalf of the application the “sign serviceagreement” procedure: a new instance of the PX SCS interface is createdinstantiated according to the service properties in the subscriptionprofile of the application (3′);

4—the PX WS performs an internal configuration phase; in the case of aParlay X Web Service with notifications during this step the newinstance of the PX SCS requires to enable the notifications subscribedby the application (4′); the PX WS stores all the information concerningthe access session requested by the application in a context;

5—the application performs (by means of WS-Security protocol) therequest of a method of the Parlay X web service to the PX WS, whichforwards the request to the interface instance of PX SCS associated tothe application (5′); such instance checks the identity of theapplication, verifies whether the use conditions are fulfilled, and,then, processes the request, by possibly invoking the SCS to access theresources (5″); if the application has not yet performed in a successfulway the initialisation phase, the PX WS returns an exception. This stepcould be repeated several times, one for each invocation performed bythe application.

FIG. 5 shows the handling of notifications to inform Parlay Xapplications of events produced by network resources.

Two cases are possible, namely:

-   -   the case described in point 6, which is just the communication        of an event that is internally processed by the application, and    -   the case described in point 7, which requires the application to        return to the Parlay X web service the results of processing of        the event.

Specifically:

6—an event notification is received by the PX SCS from a resource,possibly mediated by a SCS; the PX SCS forwards the notification to thePX WS, by including the binding information (provided in the off-lineprovisioning phase) of the web service to be invoked, as a call-back, onthe application (6′) the Parlay X web service notifies the applicationby invoking the call-back web service (by means of WS-Securityprotocol—6″);

7—an event to be handled by an application is notified to the PX SCS bya resource, possibly mediated by a SCS; the PX SCS forwards thenotification to the PX WS, by including the binding information(provided in the off-line provisioning phase) of the Web Service to beinvoked, as a call-back, on the application (7′); the PX WS notifies theapplication by invoking the call-back Web Service (by means ofWS-Security protocol); the application processes the notified event andreturns to PX WS in the response the commands that are performed by thenetwork; PX WS returns the response data to PX SCS, which processesthem.

FIG. 6 describes the interactions related to the control on the session:

8—during the period an application is using a Parlay X web service theParlay framework could challenge the application; the challenge requestis sent to the PX WS, which forwards them to the application, byinvoking the “still-alive” method (8′); the application returns theresult of the hashing of the challenging token with its password; incase the challenge fails (because either the application is not longeralive or returns a wrong answer to the challenge), the framework abortsthe access session of the application, and terminates the PX SCSinstance associated to them, and, moreover the PX WS removes the contextwith the information related to the application; invocation (8″) couldbe performed by the PX WS autonomously just to verify if the applicationis still alive;

9—during the period an application is using a Parlay X web service theapplication could challenge the Parlay X web service; the challengerequest is sent by invoking (by using WS-Security protocol) the genericmethod challenging-PXWS; the request is forwarded by the PX WS to thecorresponding PX SCS instance, which returns the result of hashing thereceived challenging token with the copy of the application password(included in the service properties received when created);alternatively it could forward the challenge to the Parlay framework;

10—if an application wants to terminate a use session with a Parlay Xweb service, it invokes (by using WS-Security protocol) the genericmethod close-session; the PX WS invokes the Parlay framework in order toterminate the access session on behalf of the application (10′); theParlay framework terminates the access session and informs the PX SCS toterminate the instance associated to the application (10″); the PX WSreleases the context associated to the application; if the applicationneeds to contact the Parlay X web service again it has to activate a newuse session, by invoking the generic method start-session on the ParlayX Web Service.

The specific implementation of the step identified in the foregoing, andthe related interactions performed in the system are based on standardParlay interfaces. These are well known in the art and do not require tobe described in detail herein.

The arrangement described herein permits a network operator that hasalready deployed a Parlay gateway to reuse it and the associatedadministrative systems in order to perform:

-   -   the authentication of software applications accessing Parlay X        web services;    -   the authorization checks on the applications to access specific        Parlay X web services;    -   the configuration of the profile containing the data        characterizing the subscription of an application to a Parlay X        web service;    -   the binding of an application to a specific Parlay X web        services, customized according to the corresponding subscription        profile data.

In the absence of such facilities a network operator would have todevelop/deploy new systems to address and configure a secure andcontrolled access to Parlay X web services from external applications.

It will be appreciated that Parlay was originally defined outside thecontext of web services (i.e. the Parlay framework was not defined toplay the role of an authentication server or an authorization server forweb services), and that the application of Parlay framework to the webservice context required to solve several technical issues.

In fact the Parlay framework and the web service technologies addresssimilar functions in opposite ways. For instance:

-   -   according to the Parlay model, an application performs an        authentication and authorization phase before performing        (several) invocations on a service interface; on the other hand,        in the web service model the execution of each invocation        includes a verification of the authentication and the        authorization of the application;    -   the authentication of an application in the Parlay model is        based on a challenge approach; on the other hand, in the web        services model the authentication servers are based on a        request-response model (see below);    -   the authentication and the authorization solutions for Parlay X        web services are able to deal with the notification of event        produced by the network resources; such aspects are not to be        considered in the Web Services case, as the web service model is        based on a request-response interaction model, where the        application performs the client/requestor role and the Web        Service the server role.

Concerning specifically authentication, one of the problems solved bythe arrangement disclosed herein relates to the procedure ofauthentication performed by the PX WS part on behalf of the requestingapplication.

Both the WS-Security “username-password” profile adopted in the detaileddescription and Parlay/OSA framework authentication processes are basedon the fact that a “shared secret”, e.g. the password associated to theapplication, is shared among the application and the server in charge ofperforming the authentication. According to the described solution, thepassword should be shared between the application and the Parlay/OSAframework: in fact, the PX WS part is just in charge to behave as aproxy in the authentication steps.

A Parlay X application that is invoking a method of a Parlay X webservice includes authentication data in each of its invocations (e.g. byusing some WS-Security mechanisms), including the applicationidentifier, the password in a digest format, and some additionalinformation (selected and/or generated by the application, e.g. atimestamp and a message identifier) used by the application to hash thepassword (e.g. the digest format of the password could be the result ofa hash algorithm that takes as an input the password, and the additionalinformation for hashing the password). In order to verify the identityof the client application, the implementation of the Parlay X webservice executes the same hash algorithm, by using as input the storedpassword associated to the application identifier and the receivedadditional information. The authentication succeeds if the result isequal to the received digest password. The same method and informationare used by the Parlay X web service implementations in order to providethe authentication data in invocations performed to notify events toapplications.

According to the API level authentication in Parlay specification (thisis the level usually supported by all the Parlay/OSA gateway products),when a Parlay application starts the authentication procedure, theframework sends a “challenge” to the Parlay application. It executesthen hash algorithm, which was previously agreed among the applicationand the framework, by combining the password and the received challenge,and return the result. The framework has to perform the same operationon the password associated to the application and stored in the gateway.The authentication succeeds if the result is equal to the data returnedby the application.

As shown in FIG. 7, in the arrangement described herein, the PX WS partper se is not able to handle the authentication steps, as it is notsharing the knowledge of the application password AP. Nor is it able tocheck the digest password d-pwd sent by the application and to answerthe challenge request sent by the Parlay framework FW.

Additionally, the authentication procedure is repeated at eachinvocation on the Parlay X web service methods performed by theapplication: also in this case there is a conflict between the twoauthentication mechanisms. In fact WS-Security requires anauthentication for each method invocation, while Parlay does not requireit (as it assumes that only the authenticated and authorizedapplications can invoke a method on an SCS interface instance during aParlay access session).

Moreover, the Parlay framework FW can send during the life-time of anaccess session some challenge to the application: the Parlay frameworkwould send the challenge to the Parlay X web service implementation,which is not able to handle it directly.

The arrangement described herein addresses all these points in a fullysatisfactory manner.

In fact, the arrangement described herein allows the Parlay frameworkfunctions to be reused fully. To that end, the Parlay X web servicebehaves as a proxy accessing the Parlay gateway on behalf of the ParlayX applications, and not as a simple Parlay application. Access a Parlaygateway according to a Proxy mode on behalf of an application istherefore a fully original approach.

By way of alternative, an optimised implementation could design the twoparts PX WS and PX SCS as a single software module, so that such a CORBAinterface could be an interface internal to the module.

Also, a Parlay X web service could be implemented directly on thenetwork elements. In that case, the corresponding PX SCS would directlyinterwork with network elements through the network protocols (e.g.INAP, SIP, MAP, etc.), without the involvement of Parlay SCSs. Moreover,also the notification handling would not require the involvement ofParlay SCSs.

The arrangement described herein is still applicable if the Parlay X webservices are invoked with a protocol for web service securityalternative to the “username-password” profile of WS-Security.

For instance:

-   -   if HTTP digest authentication is used to transport SOAP, the        information used to hash the password is proposed by the invoked        entity;    -   if the SAML-based profile of WS-Security is used, the        start-session method could return a SAML assertion generated by        the PX-WS component of the Parlay X implementation; such        assertion could be included in the following method invocation        of that Parlay X Web Service to prove that the application is        authenticated and authorised to use the Web Service.

As an alternative to using a password as a shared secret to authenticateapplications, the authentication could be based on (public and private)keys: the application uses its private key to hash the information,while the Web Service implementation uses the public key to verify thehashed information.

The contents of the WS-Security requests and responses could beencrypted, by using either the shared password or the keys.

Significantly, the arrangement described herein can also be applied tointroduce a secure and controlled access to—any—generic web services,and not only to Parlay X web services. Therefore the invention can beused to exploit the framework component of a Parlay gateway as serversfor authentication and authorization to access web services.

In fact, any generic web service can be implemented by means of thearrangement described herein, by splitting it in a WS part and in an SCSpart. Moreover, such modules would be integrated and configured in theParlay gateway as any other Parlay X web services.

It is thus evident that, the basic principles of the invention remainingthe same, the details and embodiments may widely vary with respect towhat has been described and illustrated purely by way of example,without departing from the scope of the presented invention as definedin the annexed claims.

1-22. (canceled)
 23. A method for providing to software applicationsaccess to web services, comprising the steps of: providing a Parlaygateway permitting access to web services, said Parlay gatewaycomprising a Parlay framework; and providing a set of modules comprisingservice interfaces for said software applications, the modules in saidset acting as proxies in order to perform requests for access to webservices on the framework of said Parlay gateway on behalf of saidsoftware applications.
 24. The method of claim 23, comprising the stepof configuring the modules in said set for performing authentication,authorization, and execution requests on said Parlay gateway on behalfof said software applications.
 25. The method of claim 23, comprisingthe step of providing a further set of modules configured forimplementing the behaviour of said web services once said requests onsaid Parlay framework of said Parlay gateway have been performed onbehalf of said software applications by the modules in said set.
 26. Themethod of claim 23, wherein said web services are Parlay X web services.27. The method of claim 23, comprising the step of defining at least oneweb service security protocol for ensuring secure interaction betweensaid software applications and the modules in said set.
 28. The methodof claim 23, comprising the step of providing a distributed processingmechanism enabling said modules in said set to interact with said Parlayframework in said Parlay gateway via said distributed processingmechanism.
 29. The method of claim 28, wherein said distributedprocessing mechanism is CORBA.
 30. The method of claim 25, comprisingthe step of providing a respective distributed processing mechanismenabling said modules in said further set to interact with said Parlayframework in said Parlay gateway via said respective distributedprocessing mechanism.
 31. The method of claim 30, wherein saidrespective distributed processing mechanism is CORBA.
 32. The method ofclaim 25, wherein the step of one of said software applicationsaccessing a web service comprising the steps of: said softwareapplication subscribing a module in said further set corresponding tosaid web service; and configuring the service properties of saidsubscribed module in said further set, wherein both said operations areperformed by using the tools provided by said Parlay framework in saidParlay gateway.
 33. A system for providing to software applicationsaccess to web services, comprising: a Parlay gateway permitting accessto web services, said Parlay gateway comprising a Parlay framework; anda set of modules comprising service interfaces for said softwareapplications, the modules in said set being configured for acting asproxies in order to perform requests for access to web services on theframework of said Parlay gateway on behalf of said softwareapplications.
 34. The system of claim 33, wherein the modules in saidset are configured for performing authentication, authorization, andexecution requests on said Parlay gateway on behalf of said softwareapplications.
 35. The system of claim 33, comprising a further set ofmodules configured for implementing the behaviour of said web servicesonce said requests on said Parlay framework of said Parlay gateway havebeen performed on behalf of said software applications by the modules insaid set.
 36. The system of claim 33, wherein said web services areParlay X web services.
 37. The system of claim 33, comprising at leastone web service security protocol for ensuring secure interactionbetween said software applications and the modules in said set.
 38. Thesystem of claim 33, comprising a distributed processing mechanismenabling said modules in said set to interact with said Parlay frameworkin said Parlay gateway via said distributed processing mechanism. 39.The system of claim 38, wherein said distributed processing mechanism isCORBA.
 40. The system of claim 35, comprising a respective distributedprocessing mechanism enabling said modules in said further set tointeract with said Parlay framework in said Parlay gateway via saidrespective distributed processing mechanism.
 41. The system of claim 40,wherein said respective distributed processing mechanism is CORBA. 42.The system of claim 35, wherein the modules in said further set areconfigured for permitting said software applications to access a web bythe steps of: said software application subscribing a module in saidfurther set corresponding to said web service; and the serviceproperties of said subscribed module being configured in said furtherset, wherein both said operations are performed by using the toolsprovided by said Parlay framework in said Parlay gateway.
 43. Acommunication network comprising the system of claim
 33. 44. A computerprogram product loadable in the memory of at least one computer andcomprising software portions capable of performing the method of any ofone of claims 23 to 32.